home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980901-19981211 / 000194_news@newsmaster….columbia.edu _Fri Oct 23 09:50:54 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id JAA15873
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 23 Oct 1998 09:50:54 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id JAA02407
  7.     for kermit.misc@watsun; Fri, 23 Oct 1998 09:50:53 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Stop automatic resetting of terminal emulation?
  12. Date: 23 Oct 1998 13:50:49 GMT
  13. Organization: Columbia University
  14. Lines: 51
  15. Message-ID: <70q1jp$426$1@apakabar.cc.columbia.edu>
  16. References: <Pine.WNT.4.05.9810220906420.169-100000@neko.dental.washington.edu> <zr359kB7TU8S@cc.usu.edu> <70ofhk$e9d$1@apakabar.cc.columbia.edu> <wegLF5YIzlTM@cc.usu.edu>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:9390
  19.  
  20. In article <wegLF5YIzlTM@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
  21. : ...
  22. :     Life would have been simpler if there had been both adherence to
  23. : the list of terminal names and timely expansion of the same, and vendors
  24. : who read before pressing keys. But like Unix itself, things got out of 
  25. : control irreversibly.
  26. :
  27. Especially nowadays when computers are big-business and mass-market
  28. consumer items.  The careful attention once paid to standards -- their
  29. formulation, and subsequent adherence to them -- is pretty much out the
  30. window.
  31.  
  32. Yet I believe we must support the standards process, both by participating
  33. in it and by following standards even sometimes in cases when we don't
  34. necessarily agree with them (well, within reason).
  35.  
  36. The problem at hand is what to do when the client says "I have terminal
  37. type xyz" and the host does not understand the name "xyz".  The TELNET RFCs
  38. allow two approaches.  One is simple: do nothing, in which case the user
  39. can recover by hand.  The other is to negotiate through a list until an
  40. agreeable type is found.  The tradeoffs between control (favored by the
  41. knowledgable user) and "seamlessness" (for the less knowledgable) are
  42. obvious.
  43.  
  44. The problem with the latter occurs not so much because a particular name
  45. does not appear in a list at the IANA, but because no semantics are
  46. attached to the names in the IANA terminal-type list.  Of course, when the
  47. list was started, no semantics were needed since terminal names referred to
  48. real physical devices with well-defined properties, published in technical
  49. manuals.  Nowadays, many "terminal types" exist only as software
  50. abstractions with no physical counterparts, while others are improper
  51. emulations of physical terminals that no longer exist and whose technical
  52. manuals are no longer available.
  53.  
  54. As noted previously in this discussion, the ANSI name is virtually
  55. meaningless, since many vendors (and makers of shareware, freeware, etc)
  56. have appropriated this term and applied it to their mutually incompatible
  57. products.  This gives rise to difficulties such as the one we see when
  58. trying to match terminal types between Kermit 95 and an SCO host, described
  59. in a previous posting.  The problem in this case, however, is SCO's, and was
  60. reported to them (by us) long ago, and has been addressed (partially) in SCO
  61. Open Server 5.0.5:
  62.  
  63.   http://www.sco.com/cgi-bin/ssl_reference?109521
  64.  
  65. As Jeff noted, the automatic matching of terminal type tends to be
  66. beneficial for the typical Kermit 95 user, who -- in 1998 -- is less of a
  67. tinkerer than the typical MS-DOS Kermit user.  Thus, I think MS-DOS Kermit
  68. behaves appropriately for its constituency, and so does Kermit 95.
  69.  
  70. - Frank